Thanks. I did not see this until today. There was a crash bug related to multiple events with the same image. That was an LFS bug but I came across it on my own, on 23rd December. Victor was able to avoid the crash by preventing double uses of the same image in the event list. The actual crash bug is now fixed in Test Patch D2.

WARNING: THIS IS A TEST

THIS DOES NOT CONTAIN NEW TYRE PHYSICS OR THE NEW GRAPHICS SYSTEM

PLEASE TEST BEFORE YOU POST


Hello Racers,

Here is a new test patch: 0.7D3

The changes are listed below.

0.7D3 is compatible with 0.7D

- You CAN connect online with 0.7D
- You CAN play replays from 0.7D

Please back up or rename your LFS.exe from version D so you can revert to it if necessary.


Changes from 0.7D2 to 0.7D3:

Arrows on non-race small map take colour of first name character
Speed at redline is displayed beside gear ratios in setup screen


Changes from 0.7D to 0.7D2:

Audio:

Tone variation limited to 0.99 to prevent an engine sound bug
Switched off experimental "Prevent clipping" option by default
Removed an old distortion effect from the default sound output

Misc:

Speed limiter set to 80 km/h can be manually enabled if no pit lane
Reduced glitch of multiplayer cars after TAB or fast forward replay
A small map is now displayed in layout square if there is a layout
FIX: Driver swap enabled very high speed limiter if no pit lane
FIX: Crash when two events on calendar used same event image


INSTALLATION:

A FULL version of LFS 0.7D must already be installed

To install the PATCH using the SELF EXTRACTING ARCHIVE:

1) Move or save the patch into your main LFS folder
2) Double click the patch to extract it to that folder
3) When you see "Confirm File Replace" select "Yes to All"
4) Now you can start LFS in the normal way

NOTE: You can see if the patch is correctly installed when you run
the program (LFS.exe). At the bottom of the entry screen: 0.7D3


DOWNLOAD:

IF YOU ALREADY HAVE 0.7D:
PATCH 0.7D TO 0.7D3 (SELF EXTRACTING ARCHIVE)
https://www.lfs.net/file_lfs.p ... e=LFS_PATCH_7D_TO_7D3.exe (1.1 MB)

Last edited by Victor, Sat 14 Jan 2023, 11:40.

Another 12 days have passed and some of you may be interested to read the log. The super short version is I've been fixing things, doing things that needed to be done, getting rid of lists of things to do. I'm trying to get all the important things out of the way ready to focus on tyre physics. Things that are less important, I plan to do after the release (apart from the odd thing here or there that I simply feel like doing).

The attached images show what tyre smoke looks like in a tunnel with and without a lightmap!


Log of changes:

Some small tasks to finish the delayed texture loading system
- updated per-frame task sequencer so if a car model was built a texture is not loaded
- renamed / reorganised some of the new functions to make more sense when reading code
- prevented delayed texture loading in modeller and vehicle editor (prefer instant)
- fixed single frame with headless driver standing up when exiting animation editor
- the option to switch between compressed and full skins now uses new reload system
- used MP replay to test switching between high and low resolution auto-download skins
- added critical section to make sure DDS saving cannot coincide with loading DDS skin

Spent a day on Fern Bay in the editor - various fixes (not creative work)
- unlike other tracks, Eric does not plan major Fern Bay updates in the near future
- there were shadow holes due to buildings and footbridges without top surfaces
- as an old favourite I wanted to see it in good condition suitable for release
- it's good for me to spend a little time in the track editor occasionally

Fixed minor issue: players joining in entry screen could trigger texture purge events
- host and guests did a quick load and delete of the new player's car to check setup
- as this car was loaded in "in-game" mode it would trigger a check for unused textures
- but cars no longer point to a setup in the player so this seemed to have no purpose
- so instead of preventing the cars triggering a texture purge, simply avoid this code

Off-topic interface update: Provide a left and right arrow for multi-state options
- it bugged me that to switch off replay saving I had to pass through an extra state
- now I can simply click left arrow to switch off saving / right arrow to enable
- the arrow button is greyed out if you reach the last option in that direction
- the 'greyed out' logic was easily applied to option slider bars so did that too
- tempting to do it for the integer nudge buttons but would have to change all calls
- too much to do so will forget that until the inconsistency bugs me in the future

Some development version updates
- new feature to help search for textures in the editor (in objects and world mappings)
- fixed system to load most recent version of a track for a lesson (not exact match)
- update to allow replays to load most recent version of a track (or currently loaded)
- fixed a thread protection notification exiting from editor using the window X button

Training lesson fixes
- fixed start time of training lessons which were always at midnight on 1 January 1601
- fixed some small issues around loading tracks that triggered thread warning messages
- fixed a "Game call from main thread" thread warning message during training lessons

General fixes
- fix for a thread protection notification when LFS does a full D3D recovery
(I have not seen a D3D recovery other than by deliberately forcing it to happen)

Fix for a problem noticed in MPR but would affect multiplayer generally
- symptom was a puff of smoke when clicking timeline to a certain point in the replay
- took a while to track down the cause (depended on where car was before fast forward)
- related to tyre's 'previous ground position' which is compared with current position
- this previous position was wrong if car was at a different angle before pos packet
- this has very minimal difference if pos packet is for a car that is currently viewed
- bigger difference if moving to a car that has not been viewed (physics not updated)
- solution is to get a good estimate for previous position using velocity and rotation
- testing shows that car velocity gives a good estimate so will leave out rotation now

The problem described above took me into angular momentum, rotation, position updates
- some things were still waiting since the 1000Hz updates (on my notes for months)
- now there is no sub-update, some things can be rearranged a little (for accuracy)
- a position accumulator is needed for low speeds (to avoid a 'minimum speed' issue)
- seems good to be pulling me back into physics as the tyre updates are waiting
- converted old variable FloatPos (was related to sub-updates) to position accumulator
- now super-slow speeds are possible and car cannot be stuck on 'digital rails' (xyz)

Have noticed an issue for some time - physics objects resisted starting to move
- seems to be related to 1000Hz update: object velocity not fast enough after 1 frame
- fixed by reducing the speed at which an object is considered to have started moving

Cleaned up code from recent changes / discarded finished notes / browsed old notes
- copied a few things from the old notes onto a short list of tasks to do for release
- although we are still a way from there I want to know what remains other than tyres
- random OT: made arrow keys work to move between options screens (seems like should)
- old notes reminded me that smoke particles do not pick up lighting from lightmap
- the lightmap stores info about artificial light and sky visibility, in an octree
- that means smoke looks black in the night and also too bright in tunnel during day
- made smoke particles read lightmap - see the attached images for before and after

Another week has passed and I've got rid of some more sheets of paper. The bulk of the work was allowing textures to be loaded gradually after the car's 3D model has been built. Initially it was necessary to allow number plates to be updated without rebuilding the car, for the case of a player changing their number plate while their car is on the track. Sounds obscure, but it was the last case of the car mesh being fully rebuilt while already in game. The trick was to keep a different slot for each player so the text on that slot could be updated at any time, so the number plate can change without the car model even being notified.

More obviously important was a system to allow the textures to be loaded in a delayed manner after the car mesh is built. In recent versions, a remote car's model is built only when the car comes into view, but there is a slight glitch at that point (as there always has been). I've now reduced that a lot by initially using existing special system textures for white skins and grey textures, if the texture isn't already in memory. Then the textures are loaded in subsequent frames, one by one. That doesn't take long so now if you see a white car, it won't be for long, and the glitches will be less than they were before.

It probably doesn't sound very exciting but to me it has been quite interesting to see cars loading quickly then their textures rapidly appearing over the next few frames. But I've changed it so when you load a car in the garage or click on someone's car in the game setup screen, it is always an instant load. Also when entering the game in single player or a replay the cars can be fully loaded before presenting the first frame. But for multiplayer we want to get in there as fast as possible as all connected players must be in sync. So in that case you can see cars appearing sequentially (nearest first) then all their textures are loaded and finally the number plates update. It's a better feeling than the long hold on a black screen when everyone has clicked ready.

It seems like most of my immediate notes are going to the paper recycling now. I have to do something to separate the light direction into a physical side (could be used e.g. for track temperatures) and a graphical side. In future that could relate to other weather features. Just like everything else, the physical side needs to be updated by game code and the graphical side will represent or approximate that visually.

A few other things to do and a few bugs to fix, to give me a clear head then maybe I can look at some tyre physics and reassess that, figure out what needs to be adjusted or finished to get nearer to the long awaited release.


Log of changes:

Improved editor colours when showing grids, pit zones, start positions, checkpoints
- makes it easier to find checkpoints as they need to be adjusted on all tracks

Reduced size of vertices sent to GPU by using more efficient storage for normals
- this helps memory bandwidth when drawing each frame and reduces memory usage

Adjustment to number plate system to allow plate to be updated without rebuilding car
- although a rare event this was the last remaining use of old car mesh rebuild system
- previously used to rebuild after a skin download or after pit-out glitch reduction
- now the text can be updated on the number plate texture without car being notified

System to delay loading textures all at once when the car model is built
- this is to replace the old pit-out glitch reduction that had to be removed
- it was never very nice as it resulted in white cars until your own car stopped
- new system creates texture objects in memory initially using a grey system texture
- after the car is loaded, every frame just one car texture is loaded (if not already)
- it was simple enough for the standard dds textures (but complicated a bit by mods)
- more confusing is the use of skins / skins_dds / skins_x / skins_y / mod skin folder
- the trick is to store all settings that control texture load, in the texture object
- changed the temporary texture for skins to white (looks better with user set colours)
- the temporary texture for all other textures remains grey which seems to work well
- number plate textures not updated until next frame after the last texture is loaded
- now car load, model build, texture loads, number plate creation all done separately

Fixed off topic bug: With some vehicles, exposure was noticeably wrong on entering game
- turned out that driver was not created in car setup but only when vehicle first drawn
- so eye position was not available in advance of first frame (used a default position)
- in some vehicles this could put the view in a dark place so exposure turned right up
- a result of exposure adjusting to output image + recent changes to car initialisation
- exposure usually adjusts gradually but it goes instantly to the first frame exposure

Back to the pit-out glitch, the worst remaining glitch is creation of the car model
- much reduced as it does not include loading textures (because of the recent changes)
- more of an issue could be when more than one car model is built in a graphical frame
- for instance turning last corner into pit straight, after some cars joined the race
- seems it should be possible to only allow creation of one car's model in any frame
- this would spread the stutter over a few long frames instead of one really long frame
- tested this by enabling it when entering game - cars appear one by one up the grid
- it's a good test - cars can appear individually then textures appear individually
- now the thing is to stop it happening at times like single player grid or in garage
- nice for me to see the delayed load but it's better not to see that when not needed

Last edited by Scawen, Thu 24 Nov 2022, 21:30. Reason : correction - the white and grey textures already exist (are not loaded)

Hi, here's some more progress to report. Again, I'll give a short summary and post the diary of updates.

Apart from continuing to make things thread-safe, I think the most interesting thing is a new system to make sure that a good part of the game code and data (the "Race" structure which holds Players and a lot of other data, for the game code) is not accessed by the graphics code, and also a smaller system to make sure the "Snapshot" (which is for rendering 3D and text) is not accessed by the game code. Considering that it would be quite impossible to find every line of code that is accessed in the wrong way, it's a great help to have these systems that can point out such issues whenever I come across them. It also helps me to devise more ways of restructuring the code to enforce thread safety.

Another interesting thing, at least to me is the live profiling graphs, which you can see in the attached images. LFS has always had one and it helps me to see which code uses a lot of CPU, (either because it's not well optimised or maybe there's a bug there). But it wasn't working recently due to the multithreading. I did have a CPU usage issue that forced me to sort out the multithreading version of the live profiler so I could track down the bug. Now I can select a profiler for the physics or graphics thread. The nice thing is these graphs are hierarchical, so I can click on the + buttons to see inside any section. I guess you'll know what I'm talking about if you have a look at the images. The first image shows the graphics thread CPU usage and the second image shows the physics thread CPU usage.

Here's the diary of updates:

6 Oct
Most of the day on home things (not LFS)
Afternoon / evening looked into the sound updates which can be improved
- in the most recent time graph you can see different length sound updates
- they are roughly in a 2:2:1 pattern, due to sounds being updated in 0.01s blocks
- it would be better to have variable length updates that can match frame lengths

7 Oct
Looked into sound improvements, changed the code to support variable length updates
- encountered various bugs, audio code is sometimes tricky to debug (due to timing)
- final bug was with the echo, realised there is a limit to the size of sound updates
- another obstacle I found is that the audio write point only moves in steps of 0.01s
- so it turns out I can't easily achieve the aim of variable length sound updates
- improvements have allowed me to split the sound updates over multiple physics frames
- another solution could be separate audio thread but it's too much work at the moment
Looked at FF rate - although 1000Hz is possible the options display still read 100Hz
Encountered (and fixed) thread-related crash when refreshing controllers in options
Fixed bug 'Flicker on car reset' which was thread related (wrongly reset draw values)

8 Oct
Morning with family
Looked into an issue where garage screen was initialised by game code when pitting
- that is against the rules of thread-safe behaviour in LFS code
- easily solved using a message from game code to main code to enter garage when safe
Found some bugs in Escape Menu - fixed them and improved the code for future proofing
Fixed thread-related and other minor issues with the Vehicle Editor
Moved position of "AutoJoin" which is for restarting autocross in multiplayer mode
Encountered a crash when second player joins race - related to drawing car alpha

9 Oct
Morning with family
Car alpha crash was due to removal of alpha LOD reset when car reset (bug fix 7 Oct)
- fixed by resetting alpha LOD to "do not draw" when car is created (not on reset)
Came up with another check to find code that is not thread-safe
- access "Race" structure (players, results, etc) through an access function
- this function can check that Race is only accessed from game code (not graphics)
- only trouble is the Race is accessed from around 900 lines of code... get started!
- stopped for the day after updating 400 of these lines to the new style access
- quick test already showed up two bugs for a quick fix and one more to note

10 Oct
Fixed yesterday evening's noted issue and carried on with converting Race references
Actually doing the changes makes me encounter various issues to fix along the way
It occurs to me that the Snapshot should also have the same type of protection as Race
- Race is for Game/Physics code and Snapshot (recently added system) is for graphics
Went ahead with restructuring Snapshot to an access protected version (fairly quick)
- Snapshot now contains a straight copy of the Race structure, excluding Players
- simplifies snapshot creation and makes it easier to convert code to use Snapshot
Stopped updating Race references for the day with only 164 remaining to deal with

11 Oct
Remaining references to Race have been updated to the new style after 2 hours
That is excluding some code related to skin resolution on the Misc Options screen
A race condition is revealed by the new check on switching from game setup to in-game
Also accesses to Race structure while drawing text in-game are revealed by the check
Fixed the text and entering game issues / made some changes to best lap announcement
MPR testing showed up bugs on restarting replay: crashes then invisible world issue
Clicking time bar at later point in replay is sometimes slow, sometimes fast
- learned how to reproduce the slow / fast versions of replay time clicking
- difficulty finding what extra processing takes place in the slow version
- built-in CPU profiler is currently unusable as it is not thread-safe
- looks like time to sort that out and that'll be another thing off the list
- profiler now selectable graphics / physics - used it to find the time clicking bug
Stop for the day, will fix "disappearing world on MPR restart" tomorrow

12 Oct
Fixed disappearing world on MPR restart - probably old bug unrelated to recent changes
- if layout objects were there, the occlusion octree was cleared when replay restarted
- needed to repopulate octree in that case - bug probably there since octree introduced
- for more info about the occlusion Octree see our September 2020 progress report
Back to fixing code that is not thread-safe (some identified by the new systems)
Garage was using (Player in) Race to decide which buttons to draw - now uses Snapshot
Spectate/Join wrongly used Snapshot copy of selected view (should use Game original)
Check for "Join reject" (first 12 seconds of race) needed Game and Snapshot versions
Something related to tyre warmers was called whenever a new Car was created in memory
Fixed that then spent a while cleaning up Car and Engine constructors for efficiency

More gradual progress to report. I don't think this is very interesting reading to most people but at least it shows the sort of thing I have to look into each day.

Attached an image of the updated timeline graph. It has some new colours. The reddish brown colour on the graphics thread is while it has called D3D 'Present' to apply the fully rendered image to the screen. It seems to take a long time to do that each frame because it is with Vertical Sync enabled, so it has to wait for the screen refresh (avoids tearing, and there is no point in having a higher frame rate than the monitor's refresh rate). But even during that time, the graphics card may still be rendering. The end of the blue part is only where LFS has finished sending draw instructions. The nice thing is that, with multithreading, that wait is no problem now, the physics updates keep going on as you can see.

Some gaps in the game/physics thread I believe are because my computer is so old it only has two cores (although it is a good, smooth running PC). I guess the operating system or another program wants to do something, so Windows gives a time slice to that other process instead of continuing with the LFS physics. I believe this might not happen much on a quad core.

Another thing is the audio code (yellow). Although better timed now, seems to take some time and bunch the physics updates. But this is the debug version of the code, it's a lot slower than the release build. So it might not be a problem at all.

Here's the diary of updates for any who are interested.

30 Sept
Graphical timeline showing what happens on the two threads over one second
- displays concurrency and shows where one thread can hold up the other
- reveals processing time differences between physics updates
- shows the bunching of physics updates by audio updates
- suggests better timing of audio updates

1 Oct
Timing investigation guided by the new graphical timeline
Improved accuracy of the system timer using undocumented ntdll functions
Improved the timeline a bit by adding new elements and adjusting exiting ones
Adjusted the timing of audio updates to avoid interference with the sync point

2 Oct
Adjusted game code to allow interruption of bunched physics updates for a sync point
Noticed that downloaded mods and skins are not reloaded in the best place (noted)
Made wait for sync point *always* interrupt overloaded physics (avoids visual hangs)
Noticed that game reset while physics objects moving calls D3D code 'illegally' (noted)

3 Oct
Investigating a known fault related to timer resetting when no guests are connected
Noticed some sync check values had not been updated for the 1000Hz physics update
Made some general improvements, simplified the timer reset code and fixed the bug
Moved reload of downloaded mods and cars with updated skins to the sync point
Fixed an already noted issue with auto restart on exiting the pits in hotlap mode

4 Oct
Spent some time looking at ways to delay the loading of textures when loading a car
- it would be better not do so any D3D work while loading a car but it's complicated
- some of the physics code (aero positions) depends on the 3D model being built
- possible solution is for the model to be built by game code but delay texture loading
Put that on the back burner for a while and looked at VR in the multithreading system
- found some issues including time appearing to slow down
- realised this is due to an oversight in the changes made on 2 August
- corrected that, continued VR testing, fixed a couple of bugs
Continued VR testing, looking at timing graph, experimenting

5 Oct
Another VR day, did research, testing, tried a different approach from yesterday
Ended up with good smooth results on tracks where my computer is fast enough
Did a substantial test on VR and FF wheel, driving at Bancroft and Fairfield
Force feedback can also be output at 1000 Hz with the physics updates
Seemed to feel higher resolution on the G27, I guess it could be good on DD wheel
Read through lists of things to do, would like to get a few crossed off tomorrow

Last edited by Scawen, Thu 6 Oct 2022, 07:24. Reason : not August... it's October - thanks Yisc[NL]

I've fixed that now and uploaded a C3 version.

It was a silly mistake where I had temporarily commented out some code for a test, but forgot to replace it after the test. Sorry about that!

I've adjusted the code so I can generate at different sizes.

So here is a zip file showing the current versions of:

South City (4096)
Fairfield Test Centre (4096)
Bancroft Autodrome (2048)

https://www.lfs.net/file_lfs.php?name=SO_FA_BA_bitmaps.zip

Hello Racers,

It is the 20th anniversary of Live for Speed becoming well known! According to various sources, it was on 18th August 2002 that Demo Test 0.04k first became known to more than a few people. It was very exciting to see the reaction to this new racing simulator that seemed to have appeared from nowhere and was quite different to what was available at the time. It had a focus on multiplayer racing. Despite synchronisation issues, it was already a lot of fun to race around Blackwood, with up to 8 drivers, in an XF GTI, XR GT, or XR GT TURBO.

If you'd like to try 0.04k it is available on our downloads archive page. It does not connect to the master server but it is possible to connect to a host directly by IP address.

LFS has come a long way since 2002, with 9 track areas now available and a huge variety of cars created by racers using the new mods system. Of course, there is more to come, notably a new graphics system and new tyre physics. The new graphics system includes dynamic lighting and day to night transitions. The tyre physics update is more realistic and accurate for a better driving experience.

We decided to show a few pictures of some track updates that Eric has been working on and share some technical details about the ongoing development in the physics system.

Please visit the 20th Anniversary page to see the screenshots, read about the development and watch a few short video clips.



Thank you for all the support over the last 20 years!

- LFS Developers

Hmm yeah as Flotch says, that is an old test patch.

Trouble is now as it has messed up some files I think you need to reinstall a fresh version 0.7D

I made a step forward in tyre physics last week. Although there is still a lot to do, I thought it would be good to try a test of the 1000Hz updates this week (nothing to do with tyre physics but may help with separating physics and graphics onto separate threads, along with other advantages). I was able to get a first version running in a day and worked another day searching through references to 'turns' and fixing various issues where the code had assumed that each turn was 0.01s. Now it's coded in a flexible way so I can change the update rate and recompile, to get comparisons between the 100Hz and 1000Hz versions. Actually there's a bit more searching to do but I was able to run some tests.

The good results:

The moving image is noticeably smoother. Different people have a different sensitivity to the stutter that results from the mismatch between graphical frame rate and physical update rate. As mentioned before, with a 60Hz frame rate and 100Hz physics rate, the graphical frames have physics updates like this: 2, 2, 1, 2, 2, 1...

This is known to be a worse problem in VR, with 90Hz frame rate, there are 8 graphical frames with 1 physics update, then the 9th graphical frame has 2 physics updates. So there is an extra step 10 times every second which is unpleasant when you look left or right out of your car and see scenery moving by.

That stutter can be reproduced without VR by a simple camera movement test. In full screen with vertical sync enabled, park a car in the open (e.g. at autocross) enter free view mode and look down at the car. Use left mouse button to move the car in circles or from left to right. You can see a sort of stutter or blurring at the edges of the car, or with the paint lines on the road.

With the 1000Hz version, the physics updates per graphical frame are 17, 17, 16, 17, 17, 16... which seems a lot smoother and the stutter is no longer noticeable.

Also super slow motion looked nice. Even when slowed to 1/8 speed, the physics frame rate is still 125 Hz which is more than the frame rate, so the slow motion car looks smooth.

Physics checks with the environment are more frequent, for example at 100mph we are at about 45m/s so with 100Hz updates, environment checks are every 45cm. With 1000Hz updates the environment checks are every 4.5cm. This looked good in force view as the AI driver's wheels drove over the kerbs though I have not tested FF. I don't expect to feel a difference but it could be good for people with high end DD wheels.

The bad results:

So far the CPU usage is too high. I ran a test with 10 AI cars at the start line in South City. As expected the environment checks used 10 times the CPU. The movement update also took more CPU time due to not being in a tight loop (although there are the same number of movement updates, known as sub-updates in the 100Hz version). This is assumed to be related to the cache. It's more efficient when the CPU runs a tight loop on the same data, compared with going through all the other cars and then going through all sorts of other code and data before coming back to the same data again the next frame.

Results when changing from 100Hz to 1000Hz:

10 cars on grid at new South City, physics code % of CPU time

environment checks - 2.2 up to 20.3
movement update - 3.9 up to 9.40

What next:

The movement update may be improved a little because there are no actual sub-updates, some things could be done more efficiently but I do not expect a very significant improvement.

The environment check CPU time increase is not acceptable. This 20% CPU usage is only with 10 cars and it gets far worse when the cars go through the underpass. But nearly all these environment checks are actually parts of the car (contact points and wheels) checking for collisions with nearby objects and not getting a collision at all. This suggests there is a lot of scope for optimisation. The idea is to avoid the detailed collision check in most cases if there isn't any chance of a collision. Of course, this is done to some extent already but a more accurate method is needed. The first thing to try is "Oriented Bounding Boxes" for the track segments. It's the obvious choice as it could reduce a lot of checking against fences, barriers and road surfaces. I'll need to try that and see how it goes before trying to think of other types of optimisation.

Good question but the answer is quite unknown at the moment.

In fact it's not really 10 times the workload, although there is certainly more workload. The current LFS does 'subupdates' within the physics updates. The main reason for that is the wheel object suspended between a strong spring pushing down (suspension) and another stiff spring pushing up, the physics needed a higher update rate to avoid instability in that and I think on some other areas too.

In the public version that subupdate rate is 20 times the overall physics rate. So there is a part of the car already updating at 2000 Hz. In the development version there are 10 subupdates so it's already running at 1000 Hz.

But the ray checks vs world objects (and other cars) only happen at the base physics rate, so that is only at 100 Hz. This part might be 10 times the workload, as you suggest. There is also an advantage in the existing version that the subupdates are done as a tight loop on an individual car so I assume this is good for cache access. I'm sure that expanding the tight subupdate loop into full physics frame loops will be less efficient for cache hits.

Diagram:

Current:

0.00 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
0.01 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
[0.02s elapsed]

Proposed:

0.000 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
0.001 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
[0.002s elapsed]

I really can't guess how much more work this would be. The environment checks may be 10 times, as you pointed out. I think some optimisations might help with this. The subupdates shouldn't cost any more calculations but presumably will be slowed by memory access as the 'subupdates' are no longer done on a tight loop for a single car.

I think the way forward is to go through the program, adjusting it where necessary so that I can test the two scenarios above with a simple program change (update frequency & number of subupdates). Then test the CPU usage for the physics loop and see how it compares. That sounds simple but as you may imagine, I haven't always put in a suitable multiplier when trying to work quickly to release updates. There is some code around like "do this for 100 updates" which I knew would take 1 second. But now such code needs to be changed to the equivalent of "do this for 1/update_time updates" etc. It shouldn't take too long to get for a first test just to see how the CPU usage is affected. Hopefully it's just a search for the word "turns" and look at each one to see if it needs a fix.

The word "turns" (not case sensitive) appears 671 times
The word "Turn" (case sensitive) appears 785 times

Unfortunately the word "turn" in lower case is part of the word "return" which appears 9687 times. But don't worry, I should be able to devise reasonable strategies to find the relevant lines to check.

Last edited by Scawen, Sat 11 Jun 2022, 16:46.

Thank you for the tests.

I've uploaded a last chance test patch C6 as we plan to release the full version this afternoon.

Changes from C5 to C6:

Interface:

FIX: Virtual keyboard full of question marks in Greek or Cyrillic

List of events:

Lock icon reduces width of Join button to share the usual width
Generic 'play' character added for other live streaming services

That is now available in Test Patch C5:
https://www.lfs.net/forum/thread/98309

Changes in test patch C5:

List of events:

YouTube and Twitch links are now shown as icons instead of names
A lock icon is displayed beside Join button if password required

Mods screen:

Mod name was not always shown as selected when entering mods screen

Misc:

FIX: Corrected width of characters in text dialog code page view

Thanks for the report. I've now fixed this so it will be in the next test patch (after C4).

Thanks for the report. This is fixed in Test Patch C2:
https://www.lfs.net/forum/thread/98309

I've gone with the cyan version in test patch C4.

It's not implemented on the web side so you won't see anything yet.

The fix is available for testing in Test Patch C4: https://www.lfs.net/forum/thread/98309

OK I think I have a solution. Luckily I have an old FF joystick to test.

I tried your proposed fast fix: abs(nXForce) -> nXForce

But that doesn't work properly - it resulted in reverse force when steering left.

So I tried keeping the change you suggested but also set the direction to 'right' always. This seems to work.

CODE:

This seems to have the same result on the FF joystick and I guess it would work on your wheel.

That is fixed in Test Patch C3: https://www.lfs.net/forum/thread/98309

A crash fix and a few minor updates in Test Patch C3

For the keyboard steering with arrow keys bug, please try test patch C2:
https://www.lfs.net/forum/thread/98309

For the keyboard steering with arrow keys bug, please try test patch C2:
https://www.lfs.net/forum/thread/98309

NOTE: OFFICIAL VERSION 0.7D IS NOW AVAILABLE


WARNING: THIS IS A TEST

PLEASE TEST BEFORE YOU POST


Hello Racers,

Here is a new test patch: 0.7C6

The changes are listed below.

0.7C6 is COMPATIBLE with 0.7C

- You CAN connect online with 0.7C
- You CAN play replays from 0.7C

Please back up or rename your LFS.exe from 0.7C so you can revert to it if necessary.


Changes from 0.7C5 to 0.7C6:

Interface:

FIX: Virtual keyboard full of question marks in Greek or Cyrillic

List of events:

Lock icon reduces width of Join button to share the usual width
Generic 'play' character added for other live streaming services


Changes from 0.7C to 0.7C5:

List of events:

Time to live stream is displayed if it starts in less than 1 hour
Displays current and max connections on host if any are connected
Live stream service links are now shown as icons instead of names
A lock icon is displayed beside Join button if password required

Mods screen:

If host has a limited list of mods the filters are set to show all
Page Up / Page Down keys move a whole page (5 lines instead of 4)
FIX: Selected mod's name was not always identified as selected

Force feedback:

Change in force feedback code for devices that report two FF axes
- to fix a problem with some wheels with inverted FF turning left

Interface:

Click "Join" when no official cars allowed now enters mods screen
FIX: Crash after selecting a driver name from Join Specific Host
FIX: Assigned arrow keys adjusted brake balance (etc) while driving
FIX: Viewer button was available in garage during welcome sequence
FIX: Corrected width of characters in text dialog code page view


INSTALLATION:

A FULL version of LFS 0.7C must already be installed
To install the PATCH using the SELF EXTRACTING ARCHIVE:

1) Move or save the patch into your main LFS folder
2) Double click the patch to extract it to that folder
3) When you see "Confirm File Replace" select "Yes to All"
4) Now you can start LFS in the normal way

NOTE: You can see if the patch is correctly installed when you run
the program (LFS.exe). At the bottom of the entry screen: 0.7C6


DOWNLOAD:

PATCH 0.7C TO 0.7C6 (SELF EXTRACTING ARCHIVE) (If you already have 0.7C)
EDIT: Link removed, full version is now available (1.0 MB)

Last edited by Scawen, Fri 15 Apr 2022, 14:16.